Remarks 

In the final Office Action mailed July 10, 2007: 

1. Claims 1-43 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. Patent No. 5,903,878 (Talati), in view of U.S. Patent No. 6,226,624 
(Watson). 

I Talati (U.S. Patent No. 5,903,878) 

Talati is directed to a Method and Apparatus for Electronic Commerce (title), and 
provides a system that includes an originator, a recipient and a transaction administrator (TA). 
The originator (e.g., a client or purchaser) originates an electronic commerce transaction (column 
2, lines 55-60). The recipient (e.g., a merchant or vendor) receives payment for the transaction 
(column 2, lines 60-65). The TA (e.g., a credit card authority or financial network) authenticates 
the originator and recipient and validates transaction contents (column 2, line 65 - column 3, line 
3). 

In Talati, an originator initiates a purchase or payment by sending a transaction to the 
recipient. The transaction includes some details of the purchase, along with a unique transaction 
identifier (UTID) generated by the originator. After receiving the transaction, the recipient sends 
to the TA a payment authorization request that includes the UTID. Upon receipt of the payment 
authorization request, the TA validates the originator and the recipient. Validation of the 
originator requires the TA to send to the originator a validation request that includes the UTID. 
The originator extracts the UTID and compares it to a list of generated transaction identifiers to 
determine if the transaction was initiated by the originator, (column 3, lines 4-48) 

In a claimed embodiment of Applicants' invention, a system (e.g., a verification system) 
for verifying a customer's financial instrument (e.g., credit card, bank account) initiates one or 
more transactions using that instrument. The transactions are not initiated by the customer. The 
system stores details of the transactions and later receives those same details from the customer 
to verify that the customer controls the instrument. The system compares the details offered by 
the customer to the stored details. If they match, the customer is then allowed to use the 
instrument to perform transactions. Methods claimed for verifying a financial instrument in the 
present application do not recite actions that must be performed by entities outside the 
verification system. 
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Talati does not teach or suggest all aspects of Applicants' invention for which it is cited, 
for reasons including the following. 

A. Talati Does Not "Store One or More Attributes" of one or more Transactions 
or "Receive a Set of Proffered Attributes" of the Transactions 

In claimed embodiments of the present invention (e.g., claim 1), a system for verifying a 
customer's authority to use a financial instrument initiates one or more transactions involving the 
instrument, stores one or more attributes of the transactions, then receives proffered attributes 
from the customer for comparison with the stored attributes. 

The stored attributes are specifically defined as "attributes of said one or more 
transactions" (see claim 1), and include transaction details such as number of transactions 
performed, the amount of a transaction, the type of transaction (e.g., credit, debit, deposit, 
withdrawal) and the merchant name or account used by the system for the transaction (page 2, 
lines 13-15 of the application; claims 4-7; claims 20-24). Thus, the attributes may comprise 
details of payments involving the financial instrument. 

The Examiner recognizes that Talati does not store transaction "attributes" or receive a 
set of proffered attributes of a transaction, (page 4 of the office action), but also indicates that 
Talati does "store one more attributes" (page 3 of the office action). The Examiner also asserts 
that Talati "receives a set of proffered attributes". 

In particular, the Examiner compares Applicants' stored transaction attributes and the 
attributes proffered by a customer to information in Talati given in response to security questions 
- such as a mother's maiden name, social security number or driver's license number (column 5, 
lines 33-40; column 6, lines 25-32). 

But this comparison must fail, because none of this information is part of a transaction 
involving an originator's financial instrument . In Talati, this information is used solely for the 
purpose o f validating an originator's identity , does not reflect any details of a transaction, and 
therefore cannot be equated with "one or more attributes of said one or more transactions." 

B. Talati Cannot and Does Not Compare Proffered Attributes to Stored 
Attributes of a Transaction 

In claimed embodiments of the present invention, a system for verifying a customer's 

authority to use a financial instrument initiates one or more transactions involving the 
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instrument, stores one or more attributes of the transactions, then receives proffered attributes 
from the customer and compares them with the stored attributes. If the comparison succeeds, the 
customer is permitted to use the financial instrument in a subsequent transaction. 

The Examiner rejected this aspect of Applicants' invention with reference to column 6, 
lines 33-36 of Talati, which merely states that the CA authorizes the transaction if the client 
transaction and credit limit are approved and if transaction validity has been confirmed. This 
does not suggest that one should compare stored attributes of a transaction with attributes 
proffered by a customer. 

As described above in Section LA, Talati neither stores attributes of a transaction nor 
receives from a customer proffered attributes of the transaction. Therefore, although Talati may 
issue a series of security questions for validation (e.g., mother's maiden name, social security 
number) (column 5, lines 36-40), the questions and answers do not involve attributes of a 
transaction. 

Further, even if Watson (U.S. Patent No. 6,226,624) could be interpreted as storing 
attributes of a transaction (see Section II below), like Talati it does not teach or suggest receiving 
proffered attributes of the transaction from a customer, particular after the transaction, as recited 
in claimed embodiments of the invention (e.g., claims 25-26). Thus, even by combining Talati 
and Watson, one of ordinary skill in the art would be unlikely to conceive Applicants' novel 
system and methods. 

C. Talati Does Not Accept Use of a Financial Instrument for a Subsequent 
Transaction after Matching Proffered Attributes with Stored Attributes 

In claimed embodiments of the present invention, a system for verifying a customer's 
authority to use a financial instrument initiates one or more transactions involving the 
instrument, stores one or more attributes of the transactions, then receives proffered attributes 
from the customer for comparison with the stored attributes. If the comparison succeeds, the 
customer is permitted to use the financial instrument in a subsequent transaction. 

In particular, one or more claims of the present application recite "accepting use of the 
financial instrument by the customer for a subsequent transaction if said proffered attributes 
match said stored attributes" (e.g., claim 1) or similar language. Thus, the proffered and stored 
attributes of one or more previous and completed transactions must match in order for a 
subsequent customer transaction using the financial instrument to be permitted. 
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The Examiner's rejection of this element cites column 6, lines 33-36 of Talati, and fails 
for at least two reasons: 

(1) The transaction approved in Talati is the same transaction that was validated and 
for which an originator's identity was verified, and thus is not a subsequent transaction. As 
described above in Section LA, Talati does not store or receive attributes of one or more 
transactions. Instead, for each transaction from an originator, Talati verifies the originator's 
identity using personal data of the originator (e.g., driver's license number, SSN), before the 
transaction is performed. If his/her identity is verified and the originator validates the 
transaction, the current transaction is allowed to proceed (see column 3, lines 3-6). Specifically, 
"[u]pon receipt of validation or non-validation from the originator, the TA confirms or aborts the 
transaction ..." (column 3, lines 49-50, emphasis added). 

(2) Approval of a transaction in Talati does not depend upon comparison of stored 
and proffered attributes. Instead, as the cited section of Talati states, the current transaction is 
allowed to proceed "if there is a confirmation by client 10 of transaction validity" (column 6, 
lines 35-36). Talati's confirmation of transaction validity is not the same as the comparison of 
information proffered by the originator (e.g., mother's maiden name, SSN, driver's license 
number). Transaction validity refers to the originator's comparison of a UTID received from the 
CA with the originator's list of UTIDs (column 6, lines 12-19). Therefore, Talati cannot and 
does not "accept[ ] use of the financial instrument by the customer for a subsequent transaction if 
said proffered attributes match said stored attributes" as recited in claim 1 . 

In summary, Talati: 

— authorizes use of a financial instrument for a current transaction, not a subsequent one; 

and 

— bases authorization of the current transaction on the originator's validation of the 
transaction's UTID, not a comparison of a set of stored attributes of a previous transaction 
against a set of attributes proffered by the originator. 

As described in Section II below, Watson also fails to teach or suggest this aspect of 
Applicants' invention. 

D. Talati Does Not Select Values for a Series of Transactions 

In a claimed embodiment of the present invention, a system for verifying a customer's 
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authority to use a financial account selects values for a series of transactions involving the 
account, initiates the transactions, stores a set of details of the transactions, then receives a set of 
test details from the customer for comparison with the stored details. If the comparison 
succeeds, the customer is permitted to use the financial account in a subsequent transaction. 

Talati does not select values for transactions. This element of the claims (e.g., claim 13) 
was rejected without citation to any part of Talati (page 6 of the office action). Nor could any 
part of Talati be relied upon for this subject matter. 

In particular, in Talati a transaction is initiated by an originator (column 2, lines 55-56), 
and it is the originator who specifies a value for the transaction (column 2, lines 55-59). The 
same entity that selects values (in claim 13) also initiates the transactions, stores details, receives 
test details, compares the stored and test details and authorizes use of the financial account in a 
subsequent transaction. The originator cannot be considered part of Talati 's system and the 
Talati system therefore has no control over the values of transactions. 

E. No Entity in Talati Can Perform Applicant's Method 

Performing a method described in Talati requires multiple independent entities to execute 
different operations. In particular, the originator originates an electronic commerce transaction 
and later approves or disapproves the TA's validation request. The recipient receives the 
transaction and issues a payment authorization request to the TA. The TA receives the payment 
authorization request, validates the UTID and confirms or aborts the transaction depending on 
whether the originator approves the validation request. Each of these entities (originator, 
recipient and transaction administrator) operates autonomously of each other and is incapable of 
performing the functions of any other entity. 

The entities must operate independently of each other in order to allow the originator and 
the recipient to trust that the other will perform its obligation. Thus, no one entity in Talati is 
capable of performing all elements of a claimed embodiment of Applicants' invention. For 
example, an originator may initiate a transaction using a financial instrument, but the originator 
cannot then later accept use of that financial instrument as recited in claim 1 . Use of the 
financial instrument may be accepted by the recipient in Talati, as another example, but the 
recipient does not initiate a transaction or compare stored details of the transaction to details 
offered by the originator. 
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II Watson (U.S. Patent No. 6,226,624) 

Watson is directed to a System and Method for Pre -Authorization of Individual Account 
Remote Transactions (title). As the title indicates, Watson focuses on pre-approval of individual 
transactions. 

In Watson, several entities interact during the pre-authorization of a transaction. An 
"account user" is a person or organization that uses an account to purchase goods or services. 
An "account manager" is a person or organization that monitors the account. An "authorizing 
agent" is an entity that verifies the validity of an account and authorization to use it. A "card 
issuer" or "account issuer" provides administrative service to an account manager or user, by 
providing access to the authorizing agent, for example. (Column 8, lines 8-41). 

In a typical use of the Watson system or method, a pre-authorization commences when an 
account user requests a good or service and the account manager obtains a quote (column 5, lines 
54-64). The account manager then issues a pre-authorization request to the card issuer, which 
the card issuer relays to the authorizing agent (column 5, line 65 to column 6, line 18). When the 
account user initiates the actual transaction with a merchant, the merchant initiates an 
authorization request to the authorizing agent (column 6, lines 3 1-43). The authorization agent 
then consults a table of pre-authorizations and responds accordingly to allow or deny the 
transaction (column 6, lines 44-55). 

Watson specifically states "Once a transaction is approved, the pre-authorization is spent 
and requires individual preauthorization of each transaction" (Abstract; emphasis added). Thus, 
separate pre-authorizations are needed for every transaction and each pre-authorization only 
enables a single, current, transaction. 

Watson does not teach or suggest all aspects of Applicants' invention for which it is 
cited, for reasons including the following. 

A. Watson Does Not Disclose a Transaction Processor for Initiating a 
Transaction through One or More Financial Systems 

In claimed embodiments of the present invention (e.g., claim 1), a system for verifying a 

customer's authority to use a financial instrument initiates one or more transactions involving the 

instrument, stores one or more attributes of the transactions, then receives proffered attributes 
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from the customer for comparison with the stored attributes. 

Watson does not disclose this. Watson describes a system and method for "authorizing 
an account" (column 4, line 10; column 4, line 14), "authorizing a portion of account 
transactions" (column 4, line 18), "authorizing all account transactions which without such pre- 
authorization would otherwise be denied in wholesale" (column 4, lines 32-34), etc. The system 
and methods of Watson are thus directed toward pre-authorization of a transaction and resolution 
of the pre-authorization when the transaction occurs, not a processor configured to actually 
initiate transactions. 

The cited portion of Watson (column 5, line 65 to column 6, line 18) describes the 
issuance of a pre-authorization request from an account manager to a card issuer. The pre- 
authorization request may include one or more transaction parameters and, as described above, is 
relayed to the authorizing agent. This portion of Watson may describe the pre-authorization 
process, but it does not describe a transaction processor that initiates transactions through one or 
more financial systems coupled to the transaction processor (as recited in claim 1, for example). 

For one thing, this pre-authorization procedure involves at least three entities that are, or 
should be, independent - the account manager, the card issuer and the authorizing agent. 
Secondly, in the Watson system, transactions are initiated by users (e.g., account users), not the 
Watson system. Claimed embodiments of the invention require the transaction processor, not a 
customer, to initiate a transaction. 

At best, Watson teaches one to initiate a pre-authorization request (not a transaction) for a 
transaction that will be initiated later by a user . 

B. Watson Does Not Compare Stored Attributes of a Transaction with 

Attributes Proffered by a Customer to Authorize a Subsequent Transaction 

In claimed embodiments of the present invention (e.g., claim 1), a system for verifying a 
customer's authority to use a financial instrument initiates one or more transactions involving the 
instrument, stores one or more attributes of the transactions, then receives proffered attributes 
from the customer for comparison with the stored attributes. If the attributes match, the 
customer is permitted to use the instrument for a subsequent transaction. 

Watson does not teach all of these aspects of Applicants' invention and, in fact, teaches 
the opposite. In particular, Watson may provide for the storage of "pre-authorization 
parameters" at an authorizing agent as part of the pre-authorization process of a single 
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transaction (e.g., column 6, lines 11-13). However, Watson apparently expunges these 
parameters after the transaction is completed (Abstract; column 17, lines 5-16). And, there is no 
indication that the Watson system receives proffered attributes from a user after a transaction has 
completed. Thus, Watson cannot compare stored and proffered attributes, and cannot base 
approval of a subsequent transaction on the parameters. 

Therefore, one of ordinary skill in the art who referred to Watson would be motivated to 
assemble a system and method very different from Applicants'. And, since Talati also does not 
teach these aspects of Applicants' invention, anyone referring to the combination of Talati and 
Watso would be led away from Applicants' invention. 

Ill Selected Claims 

To the extent that arguments from Applicant's Appeal Brief (filed May 11, 2006) are not 
specifically recited in this Reply, such arguments should be deemed incorporated herein and in 
no way abandoned. 

A. Claims 1-12, 29, 42-43 

(1) Claims 1 and 29 recite initiating one or more transactions using a financial 
instrument identified by a customer, storing attributes of the transactions, receiving proffered 
attributes of the transactions, comparing the proffered attributes to the stored attributes, and 
accepting the financial instrument for a subsequent transaction if the compared attributes match. 

As described above in Section I, Talati fails to receive proffered attributes of one or more 
transactions, compare the proffered attributes to stored attributes, or approve a subsequent 
transaction based on the comparison. 

And, as described in Section II, Watson does not initiate one or more transactions, 
receive proffered attributes of one or more transactions, compare the proffered attributes to 
stored attributes, or approve a subsequent transaction based on the comparison 

Further, the method of claims 1 and 29 is performed entirely within a single system. 
Talati and Watson clearly require multiple separate and independent entities in order to function. 
Thus, there is no "system" in Talati that can perform the recited method. 
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(2) Claim 8 recites the operation of a transaction processor to electronically initiate 
the one or more transactions. As specified in claim 1, the transaction processor is part of the 
system that performs the method of verifying a customer's authority to use a financial 
instrument. As described above in Section II, Watson does not teach or suggest this aspect of the 
present invention. Instead, Watson specifies that a user (e.g., an account user) initiates a 
transaction and therefore teaches away from the subject matter of claim 8. 

B. Claims 13-24 

Claim 13 recites selecting values for a series of transactions using a financial account 
identified by a user, initiating the transactions, storing details of the transactions, receiving a test 
set of details of the transactions, comparing the test set of details to the stored details, and 
accepting the financial account for a subsequent transaction if the compared details match. 

As described above in Section I, Talati does not teach or suggest "selecting values for a 
series of transactions involving the financial account." Claim 13 was rejected "by the same 
rationale" as claim 1 (page 5 of the office action), without addressing this distinct claim element, 
even though this element is not found in claim 1-12 . Therefore, claims 13-24 should be allowed. 

Also, as discussed above in Section I, Talati does not receive a test set of details (e.g., 
proffered attributes) of the series of transactions or authorize the user to conduct a subsequent 
transaction if the test set of details matches stored details of the transactions. 

C. Claims 25-26 

Claim 25 recites "prompting the user to identify details of said transactions." Claim 25 
was rejected "by the same rationale" as claim 1, despite the fact that this limitation is not found 
in claim 1 . Talati may ask a user for information unrelated to a transaction (e.g., mother's 
maiden name), but this teaches away from this aspect of Applicants' invention. 

Claim 25 also specifies that the requested details are received from a user only after the 
transactions have been completed. As described above in Section I, Talati authorizes only one 
transaction at a time, and the information the Examiner equated with Applicants' "details" must 
be received before or during the current transaction, not after . In particular, in Talati an 
originator must receive and validate a transaction before it can be completed. Watson, described 
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in Section II is similar, in that pre-authorization parameters are only used until a transaction is 
complete, and then they are expunged. 

Also, as discussed above in Section I, Talati does not receive a set of details of a previous 
transaction or authorize the user to conduct a subsequent transaction if the supplied set of details 
matches stored details of the transaction. 

Yet further, the method of claim 25 is performed entirely within a single system. Talati 
and Watson clearly require multiple separate and independent entities in order to function. Thus, 
there is no "system" in Talati that can perform the recited method. 

D. Claims 27-28 

Claim 27 recites " after the one or more transactions are completed , receiving from the 
user a second set of details" (emphasis added). Claim 27 was rejected "by the same rationale" as 
claim 1 , despite the fact that this limitation is not found in claim 1 . Indeed, as described above in 
Section I, Talati authorizes only one transaction at a time, and the information the Examiner 
equated with Applicants' "details" must be received before or during the current transaction, not 
after . In particular, in Talati an originator must receive and validate a transaction before it can be 
completed. 

Claim 27 also recites "prompting the user to identify details of said transactions." Claim 
27 was rejected "by the same rationale" as claim 1, despite the fact that this limitation is not 
found in claim 1 . Talati may ask a user for information unrelated to a transaction (e.g., mother's 
maiden name), but this teaches away from this aspect of Applicants' invention. 

Also, as discussed above in Section I, Talati does not receive a set of details of a previous 
transaction or authorize the user to conduct a subsequent transaction if the supplied set of details 
matches stored details of the transaction. 

Yet further, the method of claim 27 is performed entirely within a single system. Talati 
and Watson clearly require multiple separate and independent entities in order to function. Thus, 
there is no "system" in Talati that can perform the recited method. 
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E. Claims 30-38 

Claim 30 specifies that a test set of details of one or more transactions is received 
independently of any transaction, and that the test set of details is compared to a stored set of 
details after the one or more transactions have been completed. 

As described in Section II.B, Watson fails to teach this aspect of claim 30. Watson may 
provide for storage of particular pre-authorization parameters, but they are most certainly 
received as part of the transaction pre-authorization process - they cannot be considered 
"independent of any transaction involving the external financial account" as recited in claim 30. 
Further, the parameters are received from an "account manager", not the user. 

F. Claims 39-41 

Claim 39 specifies that a confirmation set of details of one or more transactions is 
received independently of any transaction, and that the confirmation set of details is compared to 
a stored set of details after the one or more transactions have been completed. 

Claim 39 was rejected "by the same rationale" as claim 30. But as described above, the 
rejection of claim 30 is deficient. The rejection of claim 39 is therefore deficient in the same 
manner. 



No new matter has been added with the preceding amendments. It is submitted that the 
application is in suitable condition for allowance. Such action is respectfully requested. If 
prosecution of this application may be facilitated through a telephone interview, the Examiner is 
invited to contact Applicant's attorney identified below. 



CONCLUSION 



Respectfully submitted, 



Date: August 20, 2007 



By: /DanielVaughan/ 
Daniel E. Vaughan 



42,199 

(Registration No.) 



Park, Vaughan & Fleming LLP 

2820 Fifth Street 
Davis, CA 95618 
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(530) 759-1660: voice 
(530) 759-1665: facsimile 
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